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(57) Abstract 

A system for creating and modifying intelligent tele- 
phone network call processing logic trees which can be custom- 
ized for individual customers and created in a user-friendly vis- 
ual environment (10, 15, Fig. 3-5). Service primitives are de- 
fined as logical graph nodes (20, Fig. 2, Fig. 3) which can be 
visually assembled into logic trees (Fig. 5) which represent the 
service logic flow and which provide default values for all ser- 
vice options. Higher level nodes, assembled from a plurality of 
service primitives, can likewise be defined and stored (12, 13, 
19) for later use as entities in defining yet further call process- 
ing logic trees. These call processing logic trees are interpreted 
to allow the service control point computers (17) to implement 
the services in the switched telephone network (18) by sequen- 
tially executing the specified call processing primitives. A lib- 
rary (12, 13, 19) of defined nodes and defined node assemblies 
which represent service features can thus be made available to 
permit graphical manipulation into complete logic trees repres- 
enting new services. These logic trees are then interpreted by 
generic programs in the service control point to actually pro- 
vide the described services. 
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VISUAL PROGRAMMING OF TELEPHONE NETWORK 
CALL PROCESSING LOGIC 

Technical Flrid 

This invention relates to the creation and the provisioning of 
5 special customized telephone network services for telephone subscribers and, 
more particularly, to a portable, visually programmed call processing logic 
interface for creating and provisioning such customized services. 

New telephone services are continually being developed by 

10 telephone service providers in order to meet the needs of their customers. As 
such services become available, the telephone companies, subscribers and the 
users seek yet further improvements in these services. Special services such as 
800 service, 900 service, and Private Virtual Networks (PVN) are only a few of 
the possible services bong offered. Other services might well be conceived and 

15 might well find extensive use. Unfortunately, however, new telephone services 
have heretofore required long and expensive design, testing and deployment 
activities. Such special telecommunications services are typically provided in the 
public telephone network by computer program call processing sequences residing 
in digital switches. A typical approach to providing such special services is the 

20 introduction into the telephone network of a service implementing network 
dement which interacts with die telephone network so as to implement die 
telephone services. Such service implementing network elements are variously 
called Service Adjuncts (SAs), Service Switching Points (SSPs) and Service 
Control Points (SCPs). One such Service Adjunct is disclosed in S. M. Lin and 

25 J. F. Rizzo patent 4,878,240, granted October 31, 1989. A typical Service 
Control Point is disclosed in J. J. Bemardis patent 4,782,517, granted November 
1, 1988. Finally, a typical Service Control Point is disclosed in J. O. Boese et al. 
application Serial Number 453,042, filed December 12, 1989, a continuation of 
Serial Number 125,463, filed November 25, 1987, both assigned to applicants' 

30 assignee. Each such service implementing network dement is equipped with a 
set of software-implemented service primitives which can be combined in various 
way to implement a number of telephone services. A set of such primitives for a 
Service Adjunct is disclosed in the above-mentioned Lin et d. patent. Another 
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set of primitives for a Service Switching Point is disclosed in the above- 
mentioned Bernardis et al. patent. Yet another set of such primitives for a 
Service Control Point is disclosed in "Business Services Database (BSDB): A 
Service Control Point (SGP) Application Designed to Support Private Virtual 
5 Netword (PVN) Service," Technical Advisory TA-TSY -OO0460, Issue 2, February 
1988, published by Bdl Communications Research, Inc., Red Bank, New Jersey. 
All of these sets of service-implementing primitives are, as a group, generally 
equivalent, although each is implemented in a slightly different way. 

A telecommunications network inducting such programmable 
10 special service implementing components is called an "intelligent network." Such 
networks make it possible to offer useful and profitable new services such as 800 
service, Alternate Billing service and Private Virtual Network service. Intelligent 
Network Call Processing Logic (INCPL) is the name given to the software that 
"stitches together" the appropriate service primitives to enable the Intelligent 
15 Network mechanism to implement and customize such services without the need 
for new switch software or hardware. Currently, this INCPL is custom- 
developed for each new service by a service designer, usually associated with the 
service provider, installed in the intelligent network service implementing 
component and supported by a service management system for that service. 
20 Thus, instead of the software to support a new service coming from a switch 
vendor, it can now come from a service vendor, making it possible to reduce the 
interval between service concept and service offering. Unfortunately, a great 
deal of time is still required to design custom and implement each new service. 
Moreover, since such service designs are not highly portable, further delays arise 
25 due to the need to provide widely distributed software elements to support the 
new service in a wide variety of different environments* 

Summary of the Invention 

In accordance with the illustrative embodiment of the present 
invention, these and other problems are overcome by providing a user-friendly 
30 environment in which intelligent network service primitives can be assembled 
into telephone services utilizing the graphic capabilities of a computer 
workstation. If a complete telephone service is analyzed as a graph consisting of 
nodes and edges, the nodes represent the intelligent network service primitives 
executable by the service implementing components and the edges represent the 
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order of execution of these primitives. Both action nodes and decision nodes can 
be defined in terms of the available service primitives and stored for later use in 
designing a new telephone service. Moreover, with this representation, the new 
telephone service can be displayed as a "tree" of such node primitives. Such a 
5 tree display can be manipulated graphically to create and alter the logic of a 
service. An interpreter program, designed for a particular service implementing 
component, implements such display representations with the available adjunct 
service primitives. In accordance with this invention, telephone services can be 
created, manipulated and altered by ample, user-friendly graphical 

10 manipulation. Not only can intelligent network service primitives be assembled 
graphically into new services, but service features can be defined as assemblies of 
such intelligent network service primitives and, once designed, stored in a library 
as a single node to be invoked and reused as a single entity in designing a 
plurality of future services. 

15 More particularly, graphical images or icons on a display screen are 

used to represent a reusable library of user-defined telephone service primitives. 
These images or icons can be manipulated graphically so as to assemble the 
images into logical trees representing new services or new service features. Once 
fully assembled, the electronic representation of the graphical service tree or 

20 service feature tree can be interpreted so as to actually implement the service or 
service feature. In this way, new telephone services can be designed and 
implemented much more quickly than in the prior art and thus save much of the 
expense previously associated with telephone service design and deployment. In 
addition, the extremely high level representation of telephone services implicit in 

25 the graphical service trees is an extremely portable mechanism for quickly and 
easily deploying such services without extensive reworking of service 
implementing code. Indeed, the simplicity, speed and flexibility of telephone 
service design and implementation provided with the present invention can be 
exploited to allow each individual telephone user to custom design telephone 

30 services exactly matching the needs of the customer. 

The present invention makes possible dynamic graphical creation, 
customization and provisioning of new call processing services. Using both 
simple, predefined primitive nodes and complex, user-defined constructed nodes, 
new services can be defined rapidly and with great ease. A new service is 
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created visually as a logic tree with nodes defined to re p re s ent a high-level 
abstraction of the primitive call processing actions or call processing decision 
points or combinations of such primitive actions and decision points. This tree, 
or the electronic representation of the tree, is called a Call Processing Record 
5 (GPR) since it defines exhaustively the processing necessary to provide an 
individual call with die defined service. Service providers, as well as subscribers 
themselves, can qiffftyfrr and provision the graphically defined service to satisfy 
specific customer needs by dynamically modifying and parameterizing die 
relevant graphical call processing record trees. The thus provisioned call 

10 processing records r ep r e se nting die service can then be translated from the user- 
friendly visual format to a rigorous program-generating format which can be 
generically interpreted by existing service implementing components. The 
distribution and installation of such call processing records to appropriate service 
implementing compo ne nts in an intelligent network enables die thus-described 

15 service to become instantiy available to telephone subscribers. 

There are three steps in this service specification process: 1) 
defining die node primitives, 2) establishing which nodes can be used in a 
particular service, and, 3) creating call processing records defining a particular 
service using die nodes that have been defined, and to which can be added the 

20 customer-specific parameters necessary to completely specify the service. These 
three steps can be iterated interactively to improve die quality of the resulting 
service, to remove "bugs," or to provide new features and capabilities. 

Other aspects of a service creation and provisioning system are 
disclosed and claimed in die copending applications of D. L. Babson, J. A. 

25 Bajzath, Jr. and T. C Ely, Serial Numbers , all filed of even date 

herewith and assigned to applicants' assignee. 

A complete understanding of the present invention may be gained 
by considering the following detailed description in conjunction with die 
30 accompanying drawings, in which: 

FIG. 1 shows a block diagram of an intelligent telephone network 
including a graphical telephone service design and deployment system in 
accordance with the present invention; 
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FIG. 2 shows a flowchart of the service definition, provisioning 
and implementation processes taking place in the system of FIG. 1 ; 

FIG. 3 is a graphical representation of a display screen used to 
define new telephone service primitives in the system of FIG. 1; 
5 FIG. 4 is a graphical representation of a display screen used to 

define the allowable subset of telephone service nodes which are used to design 
and implement a particular advanced telephone service in the system of FIG. 1; 
and 

FIG. 5 is a graphical representation of a display screen used m 
10 customize a logical tree template of service primitives by specifying all of lite 
customer-dependent variables required to implement a particular new service for 
a particular customer in the system of FIG. 1. 

To facilitate reader understanding, identical reference numerals are 
used to designate elements common to the figures. 

15 Detatttd Bgarigtian 

Referring more particularly to FIG. 1 of the drawings, there is 
shown a general block diagram of an intelligent network telephone service design 
and deployment system comprising a workstation 10 for designing new telephone 
services in accordance with the present invention. As will be described 

20 hereinafter, workstation 10 includes graphical facilities for defining customer 
special service nodes in terms of service control point primitives, bounding new 
special services in terms of the thus defined nodes which can be used for that 
service, and assembling these telephone service nodes into templates or 
assemblies of call processing logic units capable of providing the new telephone 

25 special services. Service creation process 11 provides the software for supporting 
these facilities and includes standard window processing capability as wdl as 
mouse or other visual selection apparatus support, and is typically stored in the 
program memory of workstation 10. Storage device 12 stores a library of the 
electronic representations of all of the nodes previously specified, both simple 

30 primitive nodes and more complex, user-defined service feature nodes. Storage 
device 13 stores the definitions of all of the services defined at workstation 10 r 
where a service definition is simply the specification of which of the defined 
nodes (primitives) can be used to implement a particular service. Storage 
device 19 stores templates of multinode fully designed services as call processing 
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records. In the present application, a "template" is a fully designed service, but 
without all of die variable parameters which are dependent on the actual 
customer using the service. Although shown as separate storage devices, 
stores 12, 13 and 19 can be contained in a single storage device. 
5 The present invention contemplates three steps in creating new 

services, defining graphical nodes from which services can be assembled (node 
definition), prescribing which nodes can be used in a particular service (service 
definition) and prescribing the logical interrelationships of the various nodes 
necessary to produce the desired service (call processing record creation). As 
10 new nodes are defined, they are stored in node library 12 for later retrieval and 
reuse. Once a new service is fully defined in terms of primitive or complex 
service nodes, a representation of that service definition is stored in a service 
definition storage facility 13. Once the service nodes are assembled into a service 
logic tree or template, that template is stored as a call processing record (CPR) 
15 in call processing record template library 19. The templates in library 19 require 
only the specification of certain customer-dependent variables required to fully 
implement the service for a particular customer. 

A services management system 14 provides administrative control 
over a plurality of service control points such as service control point 17 which 
20 actually implement the new services by exchanging network control messages 
with the switched telephone network 18. The details of the service control 
point 17, along with its interaction with the switched telephone network 18, are 
detailed in the aforementioned copending application of J. O. Boese et al. Since 
the structure and operation of the service control point 17 and the switched 
25 telephone system 18 comprise well-known telephone facilities, they will not be 
further described here. Sufficient to note that these elements are able to 
implement telephone network service primitives which can be utilized to realize 
telephone services and which are similar or identical to those disclosed in the 
aforementioned J. J. Bernardis and S. M. Lin patents and BSDB publication. 
30 Associated with the services management system 14 is a customer 

data base 16 which contains detailed information concerning the customers 
utilizing telephone network 18. Also associated with services managem ent 
system 14 is a further computer workstation 15 which can be used to add 
customer preferences and other customer specific data to the service templates 
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defined in store 19. This addition of the customer specific data to a service 
template is called "service provisioning" and permits the service templates passed 
to service control point 17 to be customized for a particular customer or set of 
customers using network 18. Workstation 15 can, of course, be combined with 

5 workstation 10 if the two workstations are at the same location. 

The workstations 10 and IS can be any modem workstation 
supporting graphical manipulation capability. One such workstation is die 
SUN 3/160 terminal running under the SUN operating system and using the 
SUNVIEW* graphics environment This environment provides window support, 

10 mouse control, and graphic creation and manipulation capability adequate to 
implement the present invention. Many other modern workstations, however, 
would likewise support implementations of the present invention. 

The present invention will be better understood by considering the 
flowchart of FIG. 2. In FIG. 2 there is shown a flowchart of the process for 

15 designing and deploying new services for telephone subscribers in accordance 
with the present invention. Three major steps are involved, node definition, 
service definition and call processing record creation. These steps will be taken 
up individually below. 

The intended user of the process of FIG. 2 is the service creator, 

20 typically the telephone service provider. As suggested in box 20 of FIG. 2, this 
person must create the nodes to be used in new services. The new nodes are 
created dynamically by specifying the following properties of the new node. 

1. Node Name 

2. Node Type 
25 3. Data Type 

4. Node Rules 

5. "Other" Allowed 

6. Node Error Message 

7. Notes 

30 As is shown in detail in FIG. 3, a node definition screen can be 

used to capture the node properties as data items. The Toad/' "Validate," 
••Store," "Delete," "Browse," "Help," and "Quit" command buttons are utilized to 
access and process nodes as entities. The data acquisition fields are used to 
define new nodes by specifying the node name and the node properties. Using 
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thcsc properties, a node can be administered by the service management 
system 14 of FIG. 1 and implemented by the service control point 17 of FIG. 1 
without the necessity of writing new service implementing code. As illustrated in 
FIG. 3, the user is presented with an on-screen form which requires that the user 
5 specify the values for each at these properties. Hie cursor initially is located at 
the first data field (NODE NAME:) and advances to successive data fields as the 
<enter> or <retura> key is depressed* Once these properties have been 
specified, the user can store the co mp l et e d node definition for the newly created 
node in a node library in store 12 (FIG. 1), using the command keys identified 
10 in the top portion of the screen display of FIG. 3. 

Hie properties captured fay the node definition screen of FIG. 3 
contain key information about the new node and, when necessary, can be 
translated and sent to the service control point 17 of FIG. 1 to drive a generic 
Gall Processing Record (GPR) interpreter (such as that disclosed in the 
15 aforementioned Bemaxdis patent), so that it can support the use of this new node 
in any call processing records that are created and provisioned for services. 
Additional or supplemental properties! such as associated service control point 
call variables, node connection rules and node translation rules, can be added to 
the node library at a later time to completely characterize the meaning and intent 
20 of these operations at a particular services management system 14 and a 
particular service control point 17 (FIG. 1) in a generic manner. More 
particularly, a specific identification erf the service implementing primitive in one 
or more service implementing network components which can be used to realize 
the node can be explicitly added to the node definition. The presence of such an 
25 identification of the actual code sequence in the service control point would 
substantially simplify the design of the interpreter program which translates the 
call processing record into actual service implementation. In this sense, the 
nodes become dements of an extendible, high level programming language for 
specifying telephone services. 
30 In response to the NODE NAME prompt, the user supplies any 

unique name chosen for the new node. This name will hereafter be used to 
identify the node. This new node name can be thought of as a higher-level 
abstraction representing a specific operation using pre-defined call processing 
variables. Nodes can be either decision nodes or action nodes. The following 
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node types, supplied in response to the NODE TYPE prompt, are possible: 
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TABLE1 
NODE TYPES 



ACTION 


DECISION 


NODES 


NODES 


Assignment Action 


Branch Decision 


Boolean Operation Action 


integer Decision 


Collect Action 


Percent Decision 


Connect Action 


String Decision 


concatenate Action 




CPR Access Action 




Diagnostic Action 




Return Action 




Table Access Action 




Temporary Hand Over Action 




Terminate Action 





The node type selected provides information that can be used 
during call processing record validation and call processing record code 
generation. These node types cor respo n d to all of the basic types of actions and 

35 decisions that might be utilized in providing telephone special services. They are 
already programmed or programmable into prior art service implementing 
network components such as service control point 17. Should a new type of node 
be required, however, it is necessary to specify the new type, and to provide 
generic implementation of the activity of the new node type in the service control 

40 point 17. 

The node types have particular meaning to service control 
point 17, which must execute the call processing record in real time. Specifically, 
tiie node type informs service control point 17 what functions or call primitives 
are to be invoked. These node types thus represent the "programmed 
45 capabilities" of service control point 17, which, when combined with the node 
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name, representing a particular pre-defined call variable in the service control 
point call processing execution environment, enable service control point 17 to 
actually perform the requested operations using the correct data. 

The DATA TYPE field specifies die format of the data that will be 
5 acceptable as input values for this node when this node is used in a call 
processing record. The data formats allowed are decimal numbers, alphanumeric 
text, telephone numbers, trunk identifiers, variable data, and baling information. 
The data type is used during call processing record validation at the time the call 
processing record is "provisioned" by the specification of customer-dependent 
10 data values. 

To administer a call processing record, services management 
system 14 of FIG. 1 must be able to determine whether valid values have been 
entered for the nodes in the the caD processing record tree. Therefore the user 
must specify the rules to be used when validating the input values for this node 

15 when this node is used in a call processing record. In accordance with the present 
invention, a regular expression can be used to represent the validation rules. 
Moreover, such validation rules can be entered dynamically in the node 
definition as opposed to hard coding them in a program. For example, to 
specify the validations for a queuing node, the user can specify the regular 

20 expression ~(lifo I fifo)$". This expression states that the node can accept either 
'last in, first out" or "first in, first out" queue behavior as input values. 

In response to the OTHER ALLOWED, prompt, the user must 
specify whether the node can accept the word "other" as an input value. For 
example, if a day of the week node were defined and available for a particular 

25 service, a call processing record would be constructed with the day of the week 
node in the tree. If the input values for the day of the week node were specified 
as "Monday and Tuesday," then a second branch would need to be created to 
cover what should be done on Saturday, Sunday, Wednesday, Thursday and 
Friday. Rather than spell out the remaining days, the string "other" could be 

30 used. For some nodes "other" is not a sensible value. Therefore, during node 
definition, the user must indicate whether "other" is a valid input value or 
whether entering "other" should result in a validation error. 

In response to the NODE ERROR MESSAGE prompt, the user 
enters a string to be printed when an inappropriate input value is specified for a 
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node during the provisioning of a call processing record. This allows "on the fly" 
validation of data entries during all succeeding uses of this node definition. 

The NOTES prompt permits a convenience field for the user. It 
can be used to note limitations on the node behavior, a general functional 
5 description of the node or any other information the user wishes to associate with 
the node (tefinitiODt 

Also shown at the top of screen 30 of FIG. 3 are a series of 
command light buttons labeled "Load,- "Validate," 'Store,- "Delete," "Browse," 
"Help," and "Quit" These command buttons axe operated, for example, by a 

10 mouse-driven cursor, to accomplish the associated sc re en display control 
functions. For example, "Load" will load any particular previously existing node 
definition (e.g., for editing) simply by giving the node name and evoking the 
"Load" command. Similarly, "Validate" performs the validation on the data 
entries made in response to the prompts. "Store" stores the newly defined node 

15 in the node library 12 of FIG. 1. The "Delete" command deletes the identified 
node definition from library 12. "Browse" allows die user to browse through all 
of the previously defined nodes, "Help" provides screens of useful ancillary 
information likely to be of assistance to the user during the node definition 
activity, and "Quit" allows the user to terminate the node definition activity. 

20 The implementation of these so-called "command buttons" are well-known in the 
art and will not be further described here. 

Returning to FIG. 2, the second box 21 represents the activity of 
defining a new service in terms of previously defined nodes. In this context, a 
"record" is a service definition and box 21 includes "Load," "Validate" and 

25 "Store" commands for these service definition records. In addition, box 21 
includes "Canvas" commands. These commands permit die visual and graphical 
manipulation of previously defined nodes into service definitions. As can be 
better seen in FIG. 4, the left half of the screen 40 is the drawing area where 
visual representations of previously defined nodes can be assembled into service 

30 definitions. The "Canvas" commands include "Clear" (to dear the canvas area), 
Draw" (to .prepare for manipulating items on the canvas), "Help" (to obtain 
screens of useful information to assist in the use of the system), and "Quit" (to 
terminate the service definition session). In addition, individual items in the 
canvas area can be manipulated with the commands "Select" (to select a 
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particular node), "Add" (to add a selected node to the service definition), •'View 0 
(to view the node definition of the selected node), and Delete" (to delete a node 
from the service definition). 

The intended user of the service definition process is the service 
5 creator. This creator utilizes the service definition process to define the subset of 
nodes in the node library that are to be used in a specific service. The user is 
presented with the form shown in FIG. 4 which enables the user to specify the 
nodes from the node library that are allowed for use by a specific service with a 
certain qualifier. A qualifier could, for example, be a specific area of service in 

10 the service provider's territory. With the functions described above, the use of 
any particular node in a service can be defined by a service creator and 
administered by the service management system 14. Once the allowable node 
names for a particular service have been specified, using the screen 40 of FIG . 4 , 
the user can store the service definition for the new service in service definition 

IS tables 12 (FIG. 1). These service definitions can thereafter be edited, 
augmented or deleted from die service definition tables 12 whenever desired. 

The service creation user can distribute the node library and the 
service definition tables in store 12 to the generic service management system 14 
for use in administering die new service. Services management system 14 will 

20 permit the use of only die specified subset of nodes in all call processing records 
that are created and provisioned for this particular service. Additional 
properties, such as service-specific node connection rules and node translation 
rules, can be added to the .service definition tables at this time to completely and 
generically characterize die meaning and intent of these operations for the service 

25 management system 14. 

Returning to FIG. 2, the box 22 represents the procedures for 
"provisioning- die service defined in box 21. In this regard, the term 
"provisioning- means creating the logic tree representing the new service and 
customizing die defined service in terms of node parameter values. The 

30 screen SO of FIG. 5 illustrates a mechanism for carrying out this process. The 
service creator can use this process to define a default representation of the 
service offering as a template of nodes interconnected in a call processing record 
tree format. The allowed nodes for a particular service are the ones specified 
through the service definition process. The service provisioning user can use this 
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process to customize the default service template and to provision the service 
with node parameter values. The user is presented with the visual progra mmin g 
tool illustrated in FIG. 5 to enable a graphical, user-friendly specification and 
input of the appropriate service customization and provisioning information, 
5 based on service, qualifier and customer key information. The qualifier could be, 
for example, a specific area of service in the service provider's territory. The 
screen of FIG. 5 provides record manipulation functions (Load Record, Validate 
Record, Store Record, and Translate Record), node manipulation functions 
(Place, Connect, Move, Edit, Disconnect, and Remove), and draw co mman ds 

10 (Select, Clear, Help, Quit, and Redraw). 

With the above described functions, the user can define a service 
template of nodes interconnected in a call processing record tree format as a 
default representation of the service offering. Furthermore, the true power of 
the present invention becomes evident when it is realized that the service creator 

IS can define modular templates of common reusable node-based logic as service 
features, which can then be added to the node library as nodes for reuse by other 
features and services. In effect, the present invention provides a mechanism for 
using the set of "programmable capabilities" available at the service control 
point 17 and define reusable, user-friendly and high-level modules that enable 

20 easier and faster visual programming of the call processing logic. 

It should be noted that assemblies of low level nodes can be 
associated together into a higher level capability which, once given a name, can 
be retrieved, manipulated and used in creating new services just like a low level 
node. In mis way, as time proceeds, the creation of new services becomes easier 

25 and e asi er since ever higher levels of service primitives become available for 
assembly into the new services. 

Once the default service template has been specified, the user can 
store the service template definition for the new service in service template 
definition store 19. The user can thereafter distribute these service template 

30 definition tables to the generic services management system 14 for use in 
administering the new service, providing a default service logic flow for the 
purpose of provisioning. Furthermore, the availability of service node definitions 
in store 13 will ensure that provisioning will support the use of only the creator- 
specified subset of nodes in any call processing records that are customized and 
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provisioned for this particular service. 

The service provider or the subscriber can also use the process 
illustrated in FIG. 5 to customize the default service template and to provision 
the service by providing node parameter values. At this stage, the node values 

5 supplied are validated dynamically by invoking the node validation rules specified 
for each node name in the node library. Additional node and service definition 
properties, such as node connection rules and node translation rules, can be 
specified to drive the validation and translation operations at the services 
management system 14 in a generic manner. 

10 The attached Appendix provides psuedocod e for implementing the 

flowchart of FIG. 2. With this pseudocode and the description herein provided, 
any person of ordinary skill in the programming art is able to fully implement 

the present invention. 

It should also be dear to those skilled in the art that further 
15 embodiments of the present invention may be made by those skilled in the art 
without departing from the teachings of the present invention. 
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APPENDIX 
Pseudocode 

Node Definition Process Pseudocode 

invoke ('node^definition') 

5 do until (invoke ('quit*)) 

if (view (node_definiticn)) 
then input (node_name) 
invoke Cloed 9 ) 

if (node.definition (nodeuname) in library 
10 then 

retrieve (node.definition (node.name)) 
display (node^definition (node.name)) 

else 

create (node.definitionjwindow (node.name)) 
15 display (node_definition_window (nodeuname)) 

endif 

end Jnvoke 

endif 

if (specify (node.properties)) 
20 then 

set_default (field_values (node_name)) 
enter (field.values (nodeuname)) 

else 

if (modify (node_properties)) 
25 then update (field.values (node.name)) 

endif 

endif 

if (validatiorucheck (node_name)) 
then 

30 invoke ('validate') 

verify (node.name, fidd.entries, fidd_entry_combinations) 
endjnvoke 

endif 

if (store (node.definition)) 
35 then 

invoke ('store') 

retrieve (nodejdefinition (nodejame)) 
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overlay (node_definition, node_properties) 
store (overlay (node.name)) 
endjnvoke 

endif 

5 if (delete (node_definition)) 
then 

invoke Cdelete 9 ) 

retrieve (node.definition (node_name)) 
delete (node.definition (node name)) 
10 endjnvoke 
endif 

if (browse (node.definition) 
then 

invoke ('browse') 
15 display (node_properties) 

retrieve (node.definitions) 
display (node_definitions) 
endjnvoke 

endif 
20 end.do 
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Service Definition Process Pseudocode 

invoke ('service.de&rition') 
do until (invoke ('quit')) 

if view (service.definition) 
5 then 

input (servicejname, service_quaHfier) 
invoke ('load*) 

retrieve (service.definition (servicejname, serivce_qualifier)) 
display (node_nameJist) 
10 endjnvoke 
endif 

if view (all_nodes) 
then 

invoke ('select 1 ) 
15 generate (menu (alLnodes)) 

endjnvoke 

endif 

if (setect_node) 
then 

20 invoke ('select') 

select (desired_node, menu (alLnodes)) 
display (desired_node, current.node.display) 
endjnvoke 

endif 

25 if use (currenUiode) 
then 

invoke (W) 

position (current.node, canvas) 
add (currenUiode, service.definition) 
30 endjnvoke 
endif 

if disallow (currcntjiode) 
then 

invoke ('delete 1 ) 
35 select (currentjiode) 

delete (selected.node) 
endjnvoke 

endif 
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if view (current_node_definition) 
then 

invoke ('view') 

select (current.node) 
5 display (node.definition, current.node) 

end_invoke 

endif 

if validate (service.definition) 
then 

10 invoke ('validate') 

verify (fidd.entries, service.definition) 
verify (field.emry_combinations, service.definitions) 
end.invoke 

endif 

15 if store (service.definition) 
then 

invoke ('store') 

retrieve (service.definition (service_name, service.qualifier)) 
overlay (service.definition (service_name, serivce.qualifier), 
20 canvas.nodes)) 

store (service.definition (service.name, service.qualifier)) 
endjnvoke 

endif 

if dear (canvas.area) 
25 then 

invoke ('dear') 

dear (all.nodes, canvas.area) 
end.invoke 

endif 

30 if redraw (canvas_area) 
then 

invoke ('draw') 

dear (all.nodes, canvas.area) 
auto.invoke ('load') 
35 endjnvoke 
endif 



end.do 
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CPR Input Process Pseudocode 

invoke ('CPRJnput*) 

do until invoke ('quit') 

if view (existing_GPR w t*ee) 
5 then 

input (service_name, qualifierjname 9 customer name) 
invoke ('load') 

retrieve (node_names (service_name t service.qualifier)) 
retrieve (node_definitions (node_names) 
10 retrieve (CPRjree (service.name, service_qualifier, 

customerjname)) 
display (CPR.tree (service.name, service.qualifier, 
customer joame)) 

endjnvoke 

15 endif 

if view (allowed_nodes ($ervice_name, service^qualifier)) 
then 

invoke ('select') 

generate (menu (aflowed.node.names)) 
20 endjnvoke 
endif 

if select (allowed_node) 
then 

invoke ('select') 
25 identify (desired_node) 

display (desired_node, current.node) 
endjnvoke 

endif 

if add (currentLCode, CPR.canvas) 
30 then 

invoke ('place') 

position (cunentLnode, CPR_canvas) 
place (current_node, CPR_canvas) 
endjnvoke 

35 endif 

if connect (node^namel, node_name2, CPR^canvas) 
then 

invoke (connect) 
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select (from_node) 
select (to.node) 

draw_line (from_node, to.node) 
endLinvoke 

5 endif 

if move (node.name) 
then 

invoke (move) 

erase (node.name, oldjocation) 
10 redraw (node_name, newjocation) 

redraw (connections, old .location, newjocation) 
endLinvoke 

endif 

if edit (node.name, node.value) 
15 then 

invoke ('edif ) 

select (node.name) 
display (editjnenu) 
input (node.value) 
20 invoke ('enter') 

erase (old.value) 
display (new.value) 
end.invoke 
endjnvoke 

25 endif 

if disconnect (node.name) 
then 

invoke ('disconnect') 
select (node.name) 
30 erase.connection (node.name, node.parent) 

endLinvoke 

endif 

if remove (node.name) 
then 

35 invoke ('remove') 

select (nodejaame) 

remove (node.name, children, connections) 
end.invoke 

endif 



40 



if validate (CPR_node) 



WO 92/11724 



PCT/US91/09456 



-22- 

then 

invoke ('validate') 

for (each node in CPR_tree) 

do 

5 validate (node_value, nodejrule) 

endjdo 

display (errorjmessages) 
correct (node_values, connections) 
endjnvoke 

10 endif 

if store (CPRjree) 
then 

invoke ('store') 

retrieve (CPRjxee (servicejname, service_qualifier, 
15 customer.nante)) 

overlay (CFR_tree (service.name, service.qualifier, 
customer_name), CPR_tree (canvas.area)) 
store (CPR_tree, overlay) 
endjnvoke 

20 endif 

if dear (canvas.area) 
then 

invoke ('dear*) 

erase (canvas.area) 
25 endjnvoke 
endif 

if redraw (canvas.area) 
then 

invoke (redraw*) 
30 erase (canvas.area) 

autojnvoke ('load') 
endjnvoke 

endif 



end.do 
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What is claimed is: 

1. A system for defining software implemented services in a 
telephone network having programmable facilities for executing customer service 
primitives, said system comprising 

5 means for specifying a plurality of reusable nodes for call 

processing record logic trees in terms of said service primitives, 

means for defining a subset of said nodes to be used in one of said 
telephone services, 

graphical means for assembling said subset of nodes into one of 
10 said call processing record logic trees, and 

means for storing said one call processing record logic tree to be 
used for providing said telephone service to a group of telephone subscribers. 

2. The system according to claim 1 wherein said means for 
specifying nodes comprises 

15 means for assembling a plurality of said nodes into a customer 

service feature call processing record logic tree, and 

means for storing and retrieving said customer service feature as a 
angle node to be used in said call processing record logic trees. 

3. The system according to claim 1 wherein said means for 
20 specifying nodes comprises 

means for specifying the name of one of said nodes. 

4. The system according to claim 1 wherein said means for 
specifying nodes comprises . 

means for specifying the node type of said one node. 
25 5, The system according to claim 1 wherein said means for 

specifying nodes comprises 

means for specifying the data type of parameter values associated 
with said one node. 

6. The system according to claim 4 wherein said means for 
30 specifying nodes comprises 

means for specifying validation rules for parameter values 
associated with said one node, and 

means for specifying an error message to be displayed in response 
to the failure of either said data type or said parameter values to satisfy said. 
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validation rules. 

7. The system according to daim 1 wherein said graphical means 
for assembling includes 

means for display selected ones of said specified nodes. 
5 8. The system according to daim 1 wherein said graphical means 

for assembling includes 

means for adding a specified node to said call processing record 

logic tree. 

9. The system according to daim 1 wherein said graphical means 
10 for assembling includes 

means for deleting a specified node from said call processing record 

logic tree. 

10. The system according to daim 1 wherein said graphical means 
for assembling includes 

15 means for interconnecting two specified nodes in said call 

processing record tree. 

11. The method for defining telephone services for 
implementation in a telephone network, said method comprising the steps of 

specifying the nodes of a plurality of call processing record trees, 
20 assembling a subset of said specified nodes to be used in a one of 

said telephone services, 

graphically interrelating said assembled nodes into a logical graph 
representing a telephone service call processing sequence, and 

storing said logical graph in a library of logical graphs to be used in 
25 providing the defined telephone service. 

12. The method according to daim 10 wherein said step of 
specifying nodes comprises the step of 

specifying the name of one of said nodes. 

13. The method according to daim 10 wherein said step of 
30 specifying nodes comprises the step of 

specifying the node type of said one node. 

14. The method according to daim 10 wherein said step of 
specifying nodes comprises the step of 
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specifying the data type of parameter values associated with said 

one node. 

15. The method according to daim 13 wherein said step of 
specifying nodes comprises the steps of 
5 specifying validation rules for parameter values associated with said 

one node, and 

specifying an error message to be displayed in response to the 
failure of either said data type or said parameter values to satisfy said validation 
rules. 

10 16. The method according to daim 10 wherein said step of 

graphically interrelating indudes the step of 

displaying selected ones of said specified nodes. 

17. The method according to daim 10 wherein said step of 
graphically interrelating indudes the step of 

15 adding a spedfied node to said call processing sequence. 

18. The method according to daim 10 wherdn said step of 
graphically interrelating indudes the step of 

ddeting a specified node from said call processing sequence. 

19. The method according to daim 10 wherein said step of 
20 graphically interrelating indudes the step of 

interconnecting two specified nodes in said call processing 

sequence. 
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